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network. 

12 Claims, 4 Drawing Sheets 



j TO FOURTH NETWORK (NOT SHOWN) j 




! :U *• 





■ T 




LOOK-UP I ' 






1 L/ 108 






rpn 


ran 




NETWORK 







LOOK-UP II 

[Taj 120 

M18 



REFERENCE 
FACTORY 



130 



134 



ELEMENT FACTORY 
SERVICE PROVIDER 



ASSOCIATIONS 
CONTAINER 



07/01/2004, EAST Version: 1.4.1 



U.S. Patent Sep. 9, 2003 Sheet 1 of 4 



US 6,618,764 Bl 



j TO FOURTH NETWORK (NOT SHOWN) j 



138 

,1 

•elemen t factory; 
i service — 



ASSOCIATIONS 
CONTAINER 



128 



ELEMENT FACTORY 
SERVICE PROVIDER 



A 

124 



126 



l 136 

t * L. 

iftEFERENCE FACTORY L 



REFERENCE FACTORY 



TO THIRD 
NETWORK 
(NOT SHOWN) • 



■ 122 



106 



LOOK-UP I 
108 



112 



k 110 



NETWORK 



-102 



114 



LOOK-UPn 
I 1^116 

LHLT 120 

j S.R. \ \ S.R. 
M18 



NETWORK n 



REFERENCE 
FACTORY 



-7 

132 
130 



134 

I 



ELEMENT FACTORY 
SERVICE PROVIDER 



ASSOCIATIONS 
CONTAINER 



FIG.1 



136 



-104 



07/01/2004, EAST Version: 1.4.1 



U.S. Patent Sep. 9, 2003 Sheet 2 of 4 US 6,618,764 Bl 



HAVi-NETWORK 



HOME API-NETWORK 



HAViFAV 
SETTOPBOX 



222 



REGISTRY 



206 



! IEEE 1394 



HA VI BAV 
TV 



208 



HAVtBAV 
D-VCR „ 



IEE1394 



202 



^210 i 



HOME API PC 
220 



DIRECTORY 



218 



SERVICE 
, PROVIDER 



IR 



SPINKLERS 




-212 216 



X-10 




LIGHTS 



7 



200 



204 



-214 



FIG. 2 



07/01/2004, EAST Version: 1.4.1 



U.S. Patent Sep. 9, 2003 Sheet 3 of 4 US 6,618,764 Bl 



302 



INTERNET 



PC 



HAW IAV/FAV SOFTWARE 
IMPLEMENTATION 



HAVISE FACTORY 



HOME API 
-320 



322 / 



DCM 
MANAGER 



324 

Jl 



REGISTRY 




306 



304 



IEEE 1394 



REFERENCE CONTAINER 




i 
r 


REFERENC 


E FACTORY 



•318 



■312 



DIRECTORY 



316 



314 



A 



HOME 
API 
OBJECT 



HAVi NETWORK 



7 



308 



HOME API NETWORK 

^ 

310 



FIG. 3 



07/01/2004, EAST Version: 1.4.1 



U.S. Patent Sep. 9, 2003 Sheet 4 of 4 US 6,618,764 Bl 



PC 



302 

-4- 



304 



HAVi BAV SOFTWARE 



HOME API ENVIRONMENT 



HAVi SE FACTORY 

"7 

320 



406- 



r 



404 



DCM 



REFERENCE 
CONTAINER 



REFERENCE 
FACTORY 



318 



312 



I 



314 



316 



J 



DIRECTORY 




HOME API 




OBJECT 



IEEE 1394 




HOME API NETWORK 

V" 

310 



40Q 



FIG. 4 



07/01/2004, EAST Version: 1.4.1 



US 6,618,764 Bl 

1 2 

METHOD FOR ENABLING INTERACTION The abstract representations are operated upon by a control- 

BETWEEN TWO HOME NETWORKS OF ler and hide the idiosyncrasies of the associated real CE 

DIFFERENT SOFTWARE ARCHITECTURES devices. The abstract representation thus provides a uniform 

interface for higher levels of software. The abstract repre- 

5 sentations are registered with their control properties. reflect- 

FIELD OF THE INVENTION mg those of the device represented. The abstract represen- 

The invention relates to a system and method for enabling tations expose their Interoperability API=s to the 

networks of possibly different software architectures, such applications and collectively form a set of services for 

as a HAVi home network and a Home API-based or a buildin S P ortable > distributed applications on the home 

JINI-based home network, to cooperate. 10 network - 

The architecture allows a device to send a command or 

BACKGROUND ART control information to another device in the home network. 

Home networks and related software architectures such as A HAVi-compliant device contains data (above abstract 

JINI of Sun Microsystems, Inc, (http://www.sun.com/jini), „ re^esenUUon referred to as Device Control Model or 

HAVi (http://www.havi.org), Home API (http:// 15 ' r oe l° w ) re '^ n S t0 its user-interface (e.g., 

www.homeapi.org), Universal-Plug-and-Play (UPnP) of GUI ) a , nd '° * co^ol capabilities. This data includes, for 

Microsoft (http://www.microsoft.com/homenet/upnp.htm), exam P le > ^ ( Java ) «»»t can be uploaded and 

have become available for application developers, device CX6Cuted ^ oth f deviC6S .° n lhe «' w °/k A HAVi- 

manufacturers and service providers. ,„ de ™* has, as a minimum, enough functionality 

20 to communicate with other devices in the system. During 

HAVi Software Architecture interaction, devices may exchange control and data in a 

T , A ,- , , . peer-to-peer fashion. This ensures that at the communication 

HAVI relates to a core of APIs (application programming ^ n(me of ^ devices ^ ^ to ^ ag ^ of 

interfaces) for digital consumer electronics appliances m a controll( , r of me s tem 0n the other hand it ^ ows a 

home network so as to provide a standard for the audio/video „ j ^ Qr controller to ; a control structure on 

electronics and the multimedia industries An API specifics £ ^ to communication model. HAVi distin- 

the method required for making requests to an operating ishes betweeQ ^ C0DtM devic6S as 

system or application program. The home network is con- explained fi^, below A controU e r is a device that acts as 

sidered a distributed computing platform .The primary goal a ^ fof & controlled device Acontro n er bosts the abstract 

of the standard referred to as the HAV,(Home Aud.o/V,deo 30 esentation for we controlled device. The control inter- 

interoperability) architecture u to ensure that products of face fa ^ yk me of ^ abgtract representation . 

different vendors can mteroperate, i.e., cooperate to perform ^ ^ ^ access mt for applicaaons t0 conlrol the 

application tasks. Current CE devices, such as home enter- d e vi cc 

tainment equipment (DVD players, DV camcorders, digital „ ™ , . , . . „ 
TV sets, etc.) are digital processing and digital storage 35 f ^'ST^fi ° E & ^ ™ ^^.<» te ^»<? as 
systems. Connecting these devices in networks makes it f °U° ws ; Fu ^V devices (FAV^) Intermediate-AV devices 
possible to share processing and storage resources. This P^ 5 ) and Base " AV devices (BAV-s). 
allows coordinating the control of several CE devices An FAV contains a complete set of the software compo- 
simultaneously, e.g., in order to simplify user-interaction. nents of the HAVi-software architecture (see below). An 
For example, a first device may instantiate recording on a 40 FAV is characterized in that it has a runtime environment for 
second device while accessing an EPG (electronic program HAVi bytecode. This enables an FAV to upload bytecode 
guide) on a third device. The home network provides the from other devices for e.g., providing enhanced capabilities 
fabric for connecting the CE devices. It allows connected for their control. An FAV may be formed by, e.g., a HAVi- 
devices to exchange both control (one device sending a compliant Set Top box, a HAVi-compliant Digital TV 
command to another) and AV (audio/video) data (one device 45 receiver, and a home PC. For example, an intelligent TV 
sending an audio or video stream to another device). The receiver can be the HAVi controller of other devices con- 
network has to meet several requirements in order to achieve nected on the network. The receiver gets the bytecode 
all this. It must support timely transfer of high-data-rate AV uploaded from another device for creating a UI for this 
streams. The network must support self-configuration, self- device and for providing external control of this device. An 
management, and hot plug-and-play. It must require low- 50 icon presenting this device can be made to appear on the TV 
cost cabling and interfaces. screen and user interaction with the icon may cause elements 
The HAVi software architecture is platform-independent of the contro1 program to actuate the represented device in 
and based on Java. HAVi uses the IEEE 1394 high- a pre-specified manner. 

performance serial bus protocol for transport of control and An IAV does not provide a runtime environment for HAVi 

content among the devices connected to the network. The ss bytecode, but may provide native support for control of 

IEEE 1394 standard is a dynamically configurable, low-cost specific devices on the home network. An IAV comprises 

digital network. IEEE 1394 defines both a backplane physi- embedded software elements that provide an interface for 

cal layer and a point-to-point cable-connected virtual bus controlling general functions of the specific devices. These 

implementations. The backplane version operates at 12.5, 25 software elements need not be HAVi bytecode and may be 

or 50 Mbits/sec. The cable version supports data rates of go implemented as native applications on the IAV that use 

100, 200 and 400 Mbits/ sec. The standard specifies the native interfaces to access other devices, 

media, topology, and the protocol. The IEEE 1394 transport A BAV may provide upload able HAVi bytecode but does 

protocol is particularly useful for supporting audio and video not host any of the software elements of the HAVi archi- 

communication protocols, due to its high data-rate capabil- tecture. A BAV is controllable through an FAV by means of 

ity. 65 the former-s uploaded bytecode. A BAV is controllable 

The HAVi architecture controls the CE devices in the through an IAV via the native code. Communication 

network through abstract representations of the CE devices. between an FAV or IAV, on the one hand, and a BAV on the 
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other hand requires that the HAVi bytecode be translated to As to device discovery: each device in the home network 

and from the command protocol used by the BAV. needs a well-defined method that allows it to advertise its 

The main software elements included in the core speci- capabilities to others. The HAVi approach is to utilize 

fication of the HAVi architecture are the ones listed below. so-called SDD daw. self describing data. The SDD data is 

For a more detailed explanation of these elements, please see 5 squired on all devices in the network. SDD data contains 

the HAVi spec, herein incorporated by reference. information about the device which can be accessed by other 

¥ * r * devices. The SDD data contains, as a minimum, enough 

1) A 1394 Communications Media Manager (CMM) — information to allow instantiation of a so-called embedded 
acts as an interface between the other software elements and device control module (embedded DCM). An embedded 
the IEEE 1394. DCM is a piece of code pre-installed on a controlling IAV 

2) An Event Manager (EM) — informs the various soft- or FAV in platform-dependent code and using native inter- 
ware elements of events in the network such as the changes faces to access the I AV=s or FAV=s resources. As mentioned 
in the network configuration that occur when appliances above, a DCM for a device is a software element that 
(devices) are added or removed from the network. provides an interface for control of general functions of the 

3) A Registry— maintains information about the appli- 15 device. Instantiation of an embedded DCM results in reg- 
ances connected to the network and the functions they offer. istration of the device=s capabilities with a registry. The 
Applications can obtain this information from the registry. registry provides a directory service and enables any object 

4) A Messaging System (MS)^erves as an API that ° n netwo * to another ob i ec 1 ° n * e network * 
facilitates communication between the software elements of Registering allows applications to infer the basic set of 
it _ v *t_ * i -m. * command messages that can be sent to a specific device on 
the various appliances on the network. The messaging 20 ^ i7 

system provides the HAVi software elements with commu- thc nctworic ' 

nication facilities. It is independent of the network and the As to communication: once an application has determined 

transport layers. A messaging system is embedded in any ^ capabilities of a device, the application needs to be able 

FAV and IAV. The messaging system is in charge of alio- t0 capabilities. This requires a general commu- 

cating identifiers for the abstract representations at the FAV 25 nication ^ cilit y applications to issue requests to 

or IAV. These identifiers are first used by the abstract devices - ^ ^ 1CC 15 provided by the HAVi messaging 

representations to register at the FAV or IAV Then they are svsl&ms ^ DCMs - ^ application sends HAVi messages 

used by the abstract representations to identify each other to D 9 Ms > . thc: DCMs ^ n ca && m P r0 P nctar y comn ™- 

within the home network. When a first abstract representa- nication with the devices. 

tion wants to send a message to another abstract represen- 30 As to HAVi message sets: in order to support level 1 

tation it has to use the identifier of the latter while invoking interoperability a well-defined set of messages is required 

the messaging API tnat must be supported" by all devices of a particular known 

5) A Device Control Module (DCM)-rcpresents an class (e^g ^e class ofTV recovers, the class of VCR=s, the 
appliance on the network. Application programs can interact clas ? of .£VD players, etc.). Tins ensures that a device can 
directly with a DCM. This shields tbem from the idiosyn- 35 work with easting devices as well as with future devices, 

• c i_ * j • • j i i- irrespective of the manufacturer, 

crasies of each individual appliance. , . .... 

^*~™,», , . ti t a. . ii These three basic requirements support a certain minimal 

6) ADCM Manager-Instalb the DCMs. It automatically f . ^ since my PF device can query thc 

reacts to changes in the network by installing new DCMs for ca p abilities of ^ other via the registly) any device can deter . 

new app ances. ^ m j ne ^ messa g C S6t SU pp 0r ted by another device. Since 

7) A Data Driven Interaction (DDI) Controller renders a applications have access to the messaging system, any 
GUI (Graphical User Interface) on a appliance=s display on devicc can interact witn ^ y othcr dcvicc . 

behalf of a HAVi software element It supports a wide range Uvel x int abilit ensures that devices can interop . 
of displays, varying from graphic^ to text-only. A DCM ^ ^ & ^ ^ of However, a more 
mayprovideauser-interface(UI).lheDCMcanpresentthe 45 extended mcchanism k QCcdcd to ^ ^ a devicc to 
UI one or more devices on the network thaUave a display. comnmnicale to other devices with additional function- 
One mechanism to achieve this is called DDI (Data Driven ^ ^ ^ nQl n[ ^ ^ embedded DC M=s on an FAV. 
Interaction). Using this mechanism, a DCM can offer a DDI For & { embedded DCM=s may not support all fea- 
descnption of its UI. Ihc description canbe retrieved by any ^ of cxisti ducts and arc unHkel {Q thosc 
HAVi-comphani ^device :with a display. The user can interact $Q ^ mw Qn&s of ^ duct cat ries . Uvel 2 
with the UI via the local d^play. A user-mteraction results in ^ 5iUt ides ^ mec hanism. To achieve this, 
messages being sent to the associated DCM for control of ^ HAyi ^ddtactot* aUows ^loadable DCM-s as an 
the physical device represented by the DCM. alternative to the embedded DCM=s mentioned above. The 

8) A Stream Manager (SMGR)—creates connections and up l oa ded DCM may replace an existing DCM on an FAV. An 
routes real-time AV streams between two or more appliances 5S up i oa dable DCM may be provided by any suitable source, 
on the network. but a likely technique is to place the upioadable DCM in the 

The HAVi architecture specifies at least two levels of HAVi SDD data of the BAV device, and upload from the 

interoperability, referred to as level 1 and level 2. BAV to the FAV device when the BAV is connected to the 

Level 1 interoperability addresses the general need to home network. Because the HAVi Architecture is vendor- 
allow existing devices to communicate at a basic level of 60 neutral, it is necessary that the uploaded DCM will work on 
functionality. To achieve this, level 1 interoperability defines a variety of FAV devices all with potentially different 
and uses a generic set of control messages (commands) that hardware architectures. To achieve this, uploaded DCMs are 
enable one device to communicate with another device, and implemented in HAVi (Java) bytecode. The HAVi bytecode 
a set of event messages that it should reasonably expect from runtime environment on FAV devices supports the instan- 
a device given its class (TV, VCR, DVD player, etc). To 65 tiation and execution of uploaded DCMs. Once created and 
support this approach a basic set of mechanisms is required: running within a FAV device, the DCM communicates with 
device discovery; communication; and a HAVi message set. the BAV devices in the same manner as described above. 
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The efficiency of level 2 interoperability becomes clear 
when one considers resources needed to access a specific 
device functionality. Level 2 allows a device to be controlled 
via an uploaded DCM that presents all the capabilities 
offered by the device, whereas to achieve similar function- 
ality in level 1, this DCM would have to be embedded 
somewhere in the network. For example, when a new device 
is added to a,network, level 1 requires that at least one other 
device comprises an embedded DCM compatible with the 
new device. In comparison, level 2 only requires that one 
device provide a runtime environment for the uploaded 
DCM obtained from the new device. 

The concept of uploading and executing bytecode also 
provides the possibility for device-specific applications 
called Device Control Applications. Through these applica- 
tions a device manufacturer can provide the user a way to 
control special features of a device without the need for 
standardizing all the features in HAVi. The application is 
provided by a DCM in HAVi bytecode and can be uploaded 
and installed by each FAV device on the network. 

For further information, reference is made to the HAVi 
specification and the IEEE 1394 specification that are avail- 
able in the public domain. The HAVi core specification has 
been made available on the web at, for example, http:// 
www.sv.philips.com/news/press, and is incorporated herein 
by reference. 

Home API Architecture 

A Home API system comprises software services and 
application programming interfaces (API=«) that allow soft- 
ware applications running on a PC to discover and interact 
with controllable devices that have registered with the 
system. The home environment may include devices such as 
TVos, VCR=»s, set top boxes, home security systems, lights, 
etc. Home API=s are protocol-independent and hide differ- 
ences in the underlying networks and inter-device commu- 
nication protocols transparent from the software applica- 
tions. The manner wherein the application accesses a device 
is uniform and independent of the underlying protocol that 
is used for communication with the device. 

Software applications interact with the devices by setting 
or getting properties of software objects created to represent 
those devices. Applications can also subscribe to events 
involving a device«s property changes in order to be notified 
of these changes. 

The Home API architecture comprises components called 
service providers. These components are dedicated to under- 
lying devices and networks and serve to translate the high- 
level operations on the software object=s properties into 
commands sent to the associated devices across the network. 
The service providers implement the Home API software 
objects. The service provider component is also responsible 
for generating property change events for the objects asso- 
ciated with the service provider. 

In more detail, Home API uses a computing model based 
on Component Object Model (COM/DCOM) technology of 
Microsoft. For more information, see, e.g., the Component 
Object Model Specification version 0.9 of October 1995 as 
supplied by Microsoft, herein incorporated by reference. 
COM is object-oriented. An object has properties that rep- 
resent control functionalities of an associated electronic 
device as exposed to a software application. A state change 
of an object as a consequence of an event from outside is 
passed on to the software application. The application 
manipulates the objects by changing or setting their prop- 
erties. When the application modifies a property of an object 
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associated with a certain physical device a command is sent 
to the associated device. 

COM is a generic mechanism allowing applications to 
communicate in a consistent way and is a framework for 

5 developing and supporting program component objects. It 
provides capabilities similar to those defined in CORBA 
(Common Object Request Broker Architecture), the frame- 
work for the interoperation of distributed objects in a 
network. OLE (object linking and embedding) provides 

30 services for the compound document that users see on their 
display, COM provides the underlying services of interface 
negotiation and event services (putting one object into 
service as the result of an event that has happened to another 
object). In this implementation clients are modeled as OLE 

15 Automation objects (abstract representations) that use prop- 
erties to expose controls and events to signal state changes. 
OLE Automation is a COM technology that enables script- 
ing and late binding of clients to servers. OLE Automation 
provides communication with other programs through calls 

20 to features (commands and queries) that the programs have 
made available for external use. Before using an object, a 
client application has first to obtain the object=s interface 
pointer. The interface pointer is obtained through the 
network=s directory by binding the object=s name or by 

25 enumerating devices. Standard COM API-s for moniker 
binding can be used. References to objects can be obtained 
by calling GetObject or CoGetObject with a string specify- 
ing the desired devices name or ID. The application can 
then manipulate the object by setting or retrieving its prop- 

30 erties through Aset propertys calls to the appropriate prop- 
erties. When an application sets or modifies a property of an 
object conesponding with a device the property -setting 
operation or modification operation is converted into a 
command that is sent across the network to the relevant 

35 device. The objects may differ in implementation, but 
expose a similar property-based model to client applications 
running on a controller, e.g., a PC with a Windows-based 
operating system. 

40 J[NI Architecture 

JINI simplifies interconnecting and sharing of devices on 
a network. In conventional systems adding a device to a PC 
or a network requires installation and boot-up. In JINI the 

45 device declares its presence and provides information about 
its functionalities. Thereupon, the device becomes acces- 
sible to other resources on the network. This technology 
enables distributed computing: capabilities are shared 
among the network=s resources. 

50 JINI focuses on the process of adding a device to the 
network and broadcasting information about the device to 
other machines. In this way, JINI provides a "Lookup" 
service that allows applications on other machines to use the 
newly added device. The approach of JINI assumes the 

55 network and operating system have already been configured 
so that each computer already knows about other computers. 
JINTs functionality occurs at a layer above the network. It 
does not, for example, solve the problems of automatic 
configuration of the network upon connection, 

60 disconnection, or reconnection. It assumes that the network 
is up or down, independent of JINI. JINI leverages the 
services provided by the network to implement its services. 

More particularly, the JINI networking infrastructure pro- 
vides resources for executing Java programming language 

65 objects, communication facilities between those objects, and 
the ability to find and exploit services on the network. By 
using Java Remote Method Invocation (RMITM), JINI 
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provides communication between objects across device fast 400 MHz Intel processors, and 32 MB RAM=s. Similar 

boundaries thus enabling those objects to work together. trends are taking place in the video games segment, where 

RMI enables activation of objects and the use of multicast to Sega and others have scheduled releases of 64-bit gaming 

contact replicated objects, providing high availability and machines. Most of the new devices come with modems or 

high reliance objects to be easily implemented in the JINI 5 other connectivity options in order to enable them to be a 

framework. RMI is an extension to traditional remote pro- part of a network. 

cedure call mechanisms. RMI allows not only data to be E acn of the above-mentioned known software architec- 
passed from object to object around the network but full tures provides a service that enables discovery of devices or 
objects, including code. Much of the simplicity of the JINI services on the network, from the abstract point of view in 
system is based on this ability to move code around the 10 a more or [ ess similar fashion. As the end result of a 
network in a form that is encapsulated as an object. JINI discovery process, a software representation of a device or 
provides a lookup service allowing services connected by a service is placed into a Look up (or Registry or Directory) 
the communication infrastructure to be found. JINI further service. The HAVi architecture registers the discovered 
provides a mechanism, referred to as Discovery/Join — for devices or services in the Registry, the JINI architecture 
JINI -enabled devices (e.g., disk drives, printers, and 15 registers them with a Look-Up service, Home API refers to 
computers) to discover the appropriate lookup service and me service as a Directory. Thereupon the registered devices 
join into the overall system. When a device joins a JINI- 0 r services become available to software applications run- 
based system, its services are added to this lookup service. nmg on the host. An application locates the software repre- 
Similarly, when a JINI-enabled device leaves the system, sentation or object and uses it according to access interfaces 
e.g., by being removed or by becoming unreliable, its 20 an( j reservation procedures of the particular software archi- 
services are deleted from the lookup service. tecture. 

For more information on home networks, especially on OHIECT OF THE INVENTION 

HAVi, the use of COM technology and OLE Automation OBJbCI OF IHb INVbNUON 

objects and Home API, and on JINI, reference is made to the a problem arises when a controlling device hosts more 

following documents, incorporated herein by reference: the 25 than one networking environment. For example, a PC with 

publicly available specifications of the HAVI architecture an 1394 connection can be part of a HAVi as well as 

(e.g., version 0.86), the specifications of the Component 0 f a Home API environment. Therefore, there is a potential 

Object Model Specification (e.g., version 0.9), the Home f or HAVi-s audio-video devices being accessible by Home 

API White Paper of March 1999 provided by the Home API API applications and, vice versa, Home API controllable 

Working Group, the JINI Architecture overview of Sun 30 devices being controlled by HAVi applications; etc. If this 

Microsystems, Inc. (including the Java Remote Invocation potential were realized in practice, users would perceive 

Specification, the Java Object Serialization Specification, these two home networking environments as one, ease of use 

the JavaSpaces Specification, etc.). would be increased and accessibility options would be 

Each one of the specific HAVi, Home API, JINI, etc., enhanced. It would also allow software developers to create 

software architectures has its own advantages and disadvan- 35 applications with a wider range of controllable devices than 

tages. was possible heretofore. 

For example, JINI allows for Java objects being trans- Further facilitating of such hybrid functionality is neces- 
ferred from one network platform environment to another sary in order to accommodate existing and emerging home 
for being run locally. On the downside, it does not always 4Q networking architectures and applications, 
leverage platform-specific features. Further, since JINI is Accordingly, it is an object of the invention to provide a 
based on Java, which is an interpreted language, it cannot method to enable bridging between different home network- 
perform as well as compiled native code. m g environments and therefore, to enable increase function - 

HAVi is designed to handle high-bandwidth IEEE1394 ality of the home network as a whole, 
audio-video equipment. It provides extensibility, through 45 qitmmarv hp thp TMVFisrrrnM 
software components (DDI, Java, etc^) downloadable from SUMMARY OF THE INVENTION 
devices, and other useful features. On the other hand, The method of the invention uses a software component 
devices that do not have an IEEE 1394 connection or (Reference Factory) in a networking environment. The corn- 
interface, cannot be easily controlled by a HAVi application. ponent detects software representations of devices or ser- 

Home API leverages Windows COM/DCOM software 50 vices available in a first network of the environment. This 

architecture and services, but it is not yet widely available on can be done through enumeration and/or monitoring of a 

other operating systems, such as UNIX, LINUX, Apple Mac Home API Directory, HAVi Registry, JINI Registry or an 

OS, etc. functionally equivalent inventory-related service on the first 

As computing or controlling devices, such as PC-s, network. Upon detection of a new software representation 
Set-top boxes, digital TV=s, VCR«s, X10 modules, etc. are ss by the Reference Factory, the latter creates a reference to be 
acquired by consumers at different times for different associated with the software representation detected on the 
purposes, it becomes important to develop solutions for first network. Such reference comprises information, e.g., a 
bridging home networks and architectures. Such software class id, a URL, an object unique identifier, an XML or DDI 
solutions are most likely to appear on relatively rich com- descriptor, etc., necessary for the creation of at least partly 
puting platforms such as PC=s, Set-top boxes, video game 60 functional representation of the device or service within 
machines, etc. Within this context, PC=s that cost $1,000 or another network software environment, 
less have continued to dominate at PC retailers over 1998 The reference information is accessed by another software 
and into 1999, with the largest growth in the segment with component (Object Factory) capable of creating such soft- 
prices below S600. PC manufacturers Emachines, Packard- ware representations (objects) making it available for the 
Bell and NEC are currently (1999) major suppliers to this 65 other network. The Object Factory creates an object if 
market segment. Emachines, for example, provides sub- necessary, or retrieves a pre -fabricated object from, e.g., a 
$600 PC-s that have high-end features such as DVD drives, web site given its URL, or passes the reference along 
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according to the rules and/or preferences of the network RATE NETWORK REPRESENTED ON HIGH DATA- 

environment it interacts with. These preferences reflect, for RATE HAVi-NETWORK. This document relates to a 

example, general architecture guidelines or specific user PC-based home automation system that uses a low data-rate 

interest. For example,. only a certain type of devices (Light) transport layer and COM-based software components, such 

is of interest to the user. Another example is a HAVi 5 as in Home API, for control of devices in a home automation 

environment where, based on the network configuration, network. The home automation system is merged with a 

only DDI representations are acceptable. messaging-based HAVi-network that uses IEEE 1394 as a 

Multiple Reference Factories can be present in a partial- high data-rate transport layer. The HAM-network controls 

lar network software architecture. Each one of them can be audio/video equipment in a home entertainment system. The 

responsible for certain types of references, such as for other 1Q home automation services and devices are registered as a 

network software environments (JINI, HAVi, Home API, HAVi-compliant elements with the HAVi network=s FAV or 

UPnP), or other object representations within such network IAV controllers. The home automation resources (devices 

(e.g., for HAVi: Java DCM, DDI data, or Native DCM), or and services) have both COM OLE Automation Interfaces 

a class of devices/services (data storage, home automation, and HAVI-compliant interfaces to permit control of the 

A/V command set, etcW). ^ home automation system from the HAVi-network. 

The invention is based on the insight to de-couple two U.S. Ser. No. 09/107,525, now U.S. Pat. No. 6,163,817, 
processes: the analysis of the network software configura- filed Jun. 30, 1998 for Yevgeniy Shteyn and Gregory 
tion on the one hand and the creation of software represen- Gewickey for DYNAMIC DE-REGISTERING OF 
tations (objects), necessary for control and/or interaction, on DEVICES IN SYSTEM WITH MULTIPLE COMMUNI- 
the other hand. Factory methods of object creation are 2Q CATION PROTOCOLS. This document relates to an infor- 
known in the art. See, for example, ADesign Patterns: mation processing system has first and second electronic 
Elements of Reusable Object-Oriented Softwares, Addison- sub -systems, and control means for controlling the sub- 
Wesley Professional Computing, by Erich Gamma, Richard systems. At least the first sub-system has a software repre- 
Helm, Ralph Johnson, and John Vlissides, October 1994, sentation registered with the control means. The control 
Addison-Wesley Pub Co; ISBN: 0201633612, especially ^ means changes a state of the first sub-system through 
pages 81-116. interacting with the software representation. The first and 

In particular, the invention relates to a method of enabling second sub-systems are also capable of interacting directly 
a first network of a first software architecture to interact with with one another without the control means being involved, 
a second network of a second software architecture. The To avoid conflicts, at least the first sub-system is capable of 
method comprises following steps: an enabling to detect a 30 de-registering with the control means so as to functionally 
first software representation of a device or of a service in the disable its software representation at the control means, 
first network; an enabling to form a reference for the first U.S. Ser. No. 08/731,624, now U.S. Pat. No. 5,959,536, 
software representation detected; and an enabling to create filed Oct. 15, 1996 for Paul Chambers and Saurabh Srivas- 
an at least partly functionally equivalent second software tava for TASK-DRIVEN DISTRIBUTED MULTIMEDIA 
representation based on the created reference and for being 3S CONSUMER SYSTEM. This document relates to a control 
accessible from the second network. The first and second system with multiple consumer electronics devices and 
networks may have identical software architectures, e.g., task-driven control means coupled to the devices for con- 
both are HAVi-based, or the first and second networks may trolling an interaction among the devices. The control means 
have different software architectures: for example, one of the acts on respective software representations of each respec- 
first and second networks is based on a HAVi architecture, 40 tive one of the consumer devices. By encapsulating the 
and the other is based on a Home API architecture; one of variable complexity of the task within a software 
the first and second networks is based on a HAVi architec- representation, it can be made as simple or as sophisticated 
ture and the other is based on a JINI architecture; one of the as needed to bring the capabilities up to a common level, 
first and second networks is based on a HAVi architecture Since the level of interface is common to the devices, 
and the other is based on a UPnP architecture; one of the first 45 applications can uniformly manipulate devices which 
and second networks is based on a JINI architecture and the embody very different levels of sophistication, 
other is based on a Home API architecture; one of the first U.S. Ser. No. 09/222,402 filed Dec. 29, 1998, now U.S. 
and second networks is based on a JINI architecture and the Pat No . 6,480,473 for Paul Chambers andSteven Curry for 
other is based on a UPnP architecture; one of the first and VERIFICATION OF ACTIVE NODES IN OPEN NET- 
second networks is based on a UPnP architecture and the 50 WORKS. This document relates to a network polling pro- 
other network is based on a Home API architecture, etc., etc. tocol which treats the network as a logical ring or linear 

Each of the examples of the software architectures men- sequence of nodes linked together. A polling request is 

tioned above has a discovery service that enables to create simply propagated down or around the network one node at 

an inventory of devices and/or services registered with the a time until a complete inventory of active nodes is 

relevant network. The method of the invention uses this 5S achieved. The protocols also includes procedures for curing 

discovery service and the Registry/Directory/Look-up func- or repairing breaks in the linking protocol and for adding 

tionality to enable to detect what is available by querying new nodes to the linking protocol. The linking protocol can 

this inventory. Then, the enabling to form comprises also be used to establish hierarchal linked networks where 

enabling to extract information about the first software top level hierarchies includes addresses to a permanent 

representation relevant to its functionality from the view- 60 member of a linked network and bottom level hierarchies are 

point of the second network; and the enabling to create a given linked network. 

comprises building a second software representation based U.S. Ser. No. 09/133,622, now U.S. Pat. No. 6,314,459, 

on the information extracted. fi i ed Aug< 13) 1998 for Lawrence Freeman for HOME- 

The following patent documents are incorporated herein NETWORK AUTOCONFIGURAriON. This document 

by reference: 65 relates to the automatic configuring of two PC-s in a 

U.S. Ser. No. 09/146,020, now U.S. Pat. No. 6,199,136, network in order to share resources registered at the indi- 

filed Sep. 2, 1998 for Yevgeniy Shteyn for LOW DATA- vidual PC-s. Services and resources local to one PC are 
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registered with the other PC and vice versa. The registry 
hides whether a service or resource is remote or local. In 
operational use of the network, a resource or service local to 
one PC is addressable from the remote PC as if it were local 
to the latter. A home network of PC=s is configured auto- 5 
matically in this manner. 

U.S. Ser. No. 09/165,683 filed Oct. 2, 1998 for Yevgeniy 
Shteyn for CALLS IDENTIFY SCENARIO FOR CON- 
TROL OF SOFTWARE OBJECTS VIA PROPERTY 
ROUTES. This document relates in particular, but not 10 
exclusively, to Home API, and relates to an information 
processing system with first and second physical compo- 
nents represented by first and second software objects. Both 
objects have properties that are changeable through calls to 
the objects. The system enables registering a property route 5 
linking a first property of the first object to a second property 
of the second object so that a change in the first property 
causes the second call being issued to the second object upon 
invoking the property route. The input call to the first object 
comprises an identifier enabling to conditionally invoke the 2Q 
route. In this manner, routes belonging to different scenarios 
are being kept independent so that the system operates more 
reliable that without scenario identifiers. 

U.S. Ser. No. 09/165,682 filed Oct. 2, 1998, now U.S. Pat. 
No. 6,434,447 for Yevgeniy Shteyn for CONTROL PROP- 25 
ERTY IS MAPPED ONTO MODALLY COMPATIBLE 
GUI ELEMENT. This document relates in particular, but not 
exclusively, to Home API, and relates to an information 
processing system that comprises an electronic device and a 
controller for control of a functionality of the device. An 30 
abstract representation of the functionality is provided to the 
controller. The abstract representation exposes a modality of 
controlling the functionality. The controller enables control- 
ling the functionality through interaction with the abstract 
representation. The modality controls associating the control 35 
of the functionality with a modally compatible controlling 
capability of the controller. The modality exposed can be, for 
example, ABooleans, Afloats, Ainteger arrays. 

U.S. Ser. No. 09/176,171 filed Oct. 21, 1998 for Doreen 
Cheng for DISTRIBUTED SOFTWARE CONTROLLED d0 
THEFT DETECTION. This document relates to providing a 
framework for a security system that is property specific. 
The framework comprises a distributed software controlled 
security system that monitors and assesses the status of 
individual property devices. The activation of an alarm and 45 
the action taken in response to the alarm are determined by 
the state of the secured property device and the rules 
associated with each state of combination of states. Depen- 
dent on the capabilities of the individual property devices 
the security functionalities are distributes among the 50 
devices. In a preferred embodiment, the communication of 
messages among the components of the system is in accor- 
dance with HAVi or Home API standards, thereby allowing 
interoperability among components of various vendors. 

U.S. Ser. No. 09/160,490 filed Sep. 25, 1998 for Adrian 55 
Turner et al., for CUSTOMIZED UPGRADING OF 
INTERNET-ENABLED DEVICES BASED ON USER- 
PROFILE. This document relates to a server system that 
maintains a user profile of a particular end-user of consumer 
electronics network-enabled equipment and a data base of 60 
new technical features for this type of equipment, e.g., a 
home network. If there is a match between the user-profile 
and a new technical feature, and the user indicates to receive 
information about updates or sales offers, the user gets 
notified via the network of the option to obtain the feature. $5 

U,S Ser. No. 09/189,535 filed Nov. 10, 1998 for Yevgeniy 
Shteyn for UPGRADING OF SYNERGE1TC ASPECTS 
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OF HOME NETWORKS. This document relates to a system 
with a server that has access to an inventory of devices and 
capabilities on a user=s home network. The inventory is, for 
example, a look-up service~as provided by HAVi, JINI and 
Home API architectures. The server has also access to a data 
base with information of features for a network. The server 
determines if the synergy of the apparatus present on the 
user=s network can be enhanced based on the listing of the 
inventory and on the user=s profile. If there are features that 
are relevant to the synergy, based on these criteria, the user 
gets notified. 

U.S. Sen No. 09/189,534 filed Nov. 10, 1998 for Yevgeniy 
Shteyn for CONTENT SUPPLIED AS SOFTWARE 
OBJECTS FOR COPYRIGHT PROTECTION. This docu- 
ment relates to the supply of content information such as a 
movie, an audio file or a textual message to an end-user. The 
content information is comprised in a software object that 
has an encapsulated procedure for end-user access of the 
content information in a runtime environment. The object 
can specify time frame for and manner wherein the content 
information is to be accessed. Since the procedure is encap- 
sulated in the object together with the content data, and since 
transport of the object over the Internet is done after 
serializing, an adequate degree of security is provided 
against unauthorized play-out or copying. 

U.S. Ser. No. 09/213,527 filed Dec. 17, 1998, now U.S. 
Pat. No. 6,499,062, for Yevgeniy Shteyn for SYNCHRO- 
NIZING PROPERTY CHANGES TO ENABLE MUL- 
TIPLE CONTROL OPTIONS. This document plates in 
particular, but not exclusively, to Home API, and deals with 
an information processing system such as a home network. 
Components on the network are represented by software 
objects whose properties can be changed through function 
calls (see COM mentioned above). Setting a property of an 
object controls the associated component. Properties are 
connected through routes that propagate state changes 
throughout the system without the need for a running client 
appUcatioa Two-way property routes are used to keep 
consistence among a controlled object and multiple control- 
ling objects without the risk of endless loops. To achieve 
this, the two-way route is executed to change a state of a 
specific one of the properties upon a change of state of 
another one of the properties if the change of state of the 
other property was caused by an effect other than the route 
itself. This mechanism enables synchronizing components 
automatically from multiple control inputs. 

The invention also allows software developers to create 
applications with a wider range of controllable devices than 
was possible heretofore, for example, in a network- 
personalizing application as discussed in U.S. Ser. No. 
09/160,490 filed Sep. 25,1998 for Adrian Turner et al., and 
U.S. Ser. No. 09/189,535 filed Nov. 10,1998 for Yevgeniy 
Eugene Shteyn for:,UPGRADING OF SYNERGETIC 
ASPECTS OF HOME NETWORKS, mentioned above. For 
personalizing services also see U.S. Ser. No. 09/283,545 
filed Apr. 1, 1999 for Yevgeniy Eugene Shteyn for TIME- 
AND LOCATION-DRIVEN PERSONALIZED TV, incor- 
porated herein by reference. This document relates to a 
server system and method that enable a subscriber to select 
a specific broadcast program for recording and a specific 
location and time frame for play-out of the recorded pro- 
gram. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The invention is explained by way of example and with 
reference to the accompanying drawings, wherein: 
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FIG. 1 is a block diagram of a system illustrating the software representations based on the information contained 

invention; in the references chosen and suitable for being installed on 

FIG. 2 is a block diagram of a HAVi/Home API hardware network 102, e.g., by registering or placing with service 106 

configuration; and according to the rules specified by the software architecture 

FIGS. 3 and 4 are block diagrams illustrating software 5 of network 102 * Upon registering with service 106 the 

configurations for a HAVi-Home API system. resources on network 104 become accessible and control- 

* u , „ t i • j * a lable from network 102. 

Throughout the figures, same reference numerals indicate , . , . . _ 

• ;1 _ *! f^*,™ Factory 124 is able to use the rules of the software 

similar or corresponding features. / . 1AJ . , . • i<ia 

architecture of network 104 in order to access service 114 

PREFERRED EMBODIMENTS 10 anc * extract information to create the references. Factory 128 

is able to use the rules of the software architecture of 
The invention enables home networks of different soft- network 102 in order to access service 106 for registering 
ware architectures to be integrated with each other. Refer- ncw i y CTe ated software representations based on the refer- 
ences to software representations of devices and services on ences i n repository 126. Factory 126 and Factory 128 
a first one of the networks are automatically created. The is interface via repository 126. Repository 126 should there- 
references are semantically sufficient to enable automatic fore be capable of communicating the information content of 
creation of at least partly functionally equivalent software the references created by Factory 124 to Factory 128. A 
representations, for a second one of the networks so as to possible mechanism to accomplish this is to have Factories 
make the devices and services of the first network accessible 124 and 128 expose an interface to repository 126 based on 
from the second network. 20 the same language, e.g., XML. That is, the references 
ni - n . n supplied as output by Factory 124 are directly useable as 
blocK Diagram Concepts ^ tQ Factory us Another mechanism is to have reposi- 

HG.l is a block diagram of a system 100 to illustrate the tory 126 be capable of translating or converting the infor- 

invention. System 100 comprises first and second networks mation received from Factory 124 into suitably formatted 

102 and 104 that have different software architectures. For 25 output to Factory 128 using a conversion protocol. Within 

example, network 102 has a HAVi-based architecture and this context see, e.g., U.S. Ser. No. 09/165,682 (attorney 

network 104 has a Home API-based architecture, or network docket PHA 23,484) referred to above, illustrating a generic 

102 has a JINI-based architecture and network 104 has a kind of mapping protocol. Alternatively, specific conversion 

HAVi architecture, etc. stages can be inserted between repository 126 on the one 

First network 102 has a service 106 that enables querying 30 nand and networks 102 and 104 on the other hand, 
software representations 108, 110, . . . , 112 of resources Mutatis mutandis, a similar means 130 may be added that 
(devices and services) that have registered with network comprises a Reference Factory 132, a Container 134 and a 
102, The querying scans the attributes of representations Software Element Factory 136 to make the resources on 
108-112. Service 106 enables registering, unregistcring and network 102 controllable from network 104. 
querying of resources that can controlled and made to 35 Multiple Reference Factories may be installed on network 
interact. Registering a resource requires a set of attributes 104, for example a further Reference Factory 136 for 
and a reference for the representation. Unregistering providing specific reference information in order to enable a 
requires providing the same reference and disabling access third network (not shown) of yet another software architec- 
to the reference by software applications or other software hire to control one or more functionalities registered with 
objects. Querying involves providing a complete or partial 40 network 104 similarly to the control from network 102. Each 
set of attributes against which to match the registered of these multiple Reference Factories can be responsible for 
entries. Similarly, network 104 has a service 114 that enables certain types of references, e.g., another software environ- 
to discover and control resources that have their software ment (HAVi, JINI, Home native DCM for IAV etc.), or a 
representations 116, 118, 120 registered with it. class of resources (devices/services), e.g., data storage, 

System 100 has means 122 that bridges networks 102 and home automation, A/V command set, etc. 

104 and serves to provide to network 102 control over one Repository 126 may be accessible to a further Software 

or more resources registered with network 104. Element Factory 138 for a fourth network, the further 

Means 122 comprises a software module (an object or an Factory being capable of directly or indirectly handling the 

application) 124, called a Reference Factory. Reference 50 references in repository 126. 

Factory 124 is installed on network 104 and has access to „ , „ „ J _ „ 

any of software representations 116-120 through service Block Dia S ram Hardware Configuration HAVi- 

114. Reference Factory 124 is capable of querying the Home API 

inventory of service 114 or of getting notified of a new FIG.2 illustrates the physical configuration of an inte- 

software representation according to the methods of the 5S grated home network system 200 comprising a HAVi -based 

software architecture of network 104, In this sense Factory network 202 and a network 204 based on Home API. 

124 is specific to network 104. When Reference Factory 124 Network 202 comprises a HAVi set top box 206 with FAV 

has found an object of interest, e.g., software representation capabilities (see HAVi discussion above), a HAVi compliant 

116, Factory 124 creates a reference or a set of references to jy 208 serving as a BAV (see HAVi discussion above) and 

representation 116. 60 a HAVi compliant D-VCR 210 also serving as a BAV. 

Means 122 further has an Associations Container 126,a Devices 206, 208 and 210 are interconnected through a 

software representation for a repository for the references IEEE 1394 bus so as to enable set top box 206 to control TV 

created by Factory 122 in order to make them available to all 208 and D-VCR 210. 

clients of network 104. Network 204 comprises a PC 212 that is configured to 

Means 122 also has a Software Element Factory 128 that 65 control lights 214 via an X-10 connection, lawn sprinklers 

is installed on network 102. Factory 128 chooses references 216 via an IR connection, and other appliances (not shown) 

from Container 126 and creates or retrieves pre-fabricated via associated connections. 
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Software Element Factory 320, interacting with other BAV 
software components in order to represent Home API object 
314 as a DCM 406 (or an FCM) on HAVi network 308. 
DCM managers) (not shown) on HAVi FAV "or IAV devices 
interact with BAV software 404 in order to make Home API 
object 314 available on network 308 through DCM 406. 

Also see U.S. Ser. No. 09/146,020 now U.S. Pat. No. 
6,199,136, listed above for this configuration. 

Within the context of installing Software Elements, ref- 
erence is made to U.S. Ser. No. 09/160,490 filed Sep. 25, 
1998 for Adrian Turner et al., for CUSTOMIZED 
UPGRADING OF INTERNET-ENABLED DEVICES 
BASED ON USER-PROFILE, mentioned above, and to 
U.S. Ser. No. 09/189,535 filed Nov. 10,1998 for Yevgeniy 
Eugene Shteyn for UPGRADING OF SYNERGETIC 
ASPECTS OF HOME NETWORKS, mentioned above. 

As another example, a HAVi-UPnP bridge is built by 
exposing HAVi software elements to the UPnP network and 
vice versa. XML is the basis for the representation of devices 
in UPnP. In order to participate in a UPnP network HAVi 
software elements need to have an XML representation 
associated with them. Such a representation can be created 
"on the fly", i.e., each time per connection/enumeration 
request, or, preferably, once and placed in the Registry as an 
attribute of the Software Element or a separate Software 
Element associated with the first one by a unique Software 
Element ID. If a direct translation to XML of a specific HAVi 
software element is functionality not possible (e.g., a soft- 
ware element is represented by a third-party Java object, 
etc . . . ), a generic XML representation can be created. The 
Software Element (DCM, FCM) manufacturer may provide 
a preferred XML representation of the component, if par- 
ticipation in the UpnP network is intended. Similarly, the 
HAVi DDI interface can be translated into XML, based on 
the published DDI user interface elements (see, e.g., section 
4 of the HAVi specification for further details). The Java 
reflection mechanism can be used to query interfaces of a 
particular Java object and an equivalent XML model can be 
created if the interface is found to be known. 

I claim: 

1. A method of enabling a first home network of a first 
software architecture to interact with a second home net- 
work of a second software architecture that is different from 
the first software architecture, the method comprising: 
detecting a first software representation of a device or of 
a service that is registered in the first network, the first 
software representation being comprised of a device or 
service -specific API that enables software applications 
within the first network to control interaction with a 
first respective set of one or more functionalities of the 
device or service in accordance with the first software 
architecture; 

in response to detection of the first software 
representation, forming a reference of the first software 
representation, the reference comprising information 
defining the functionalities performed by the device or 
service that are relevant to the second network; 

creating an at least partly functionally equivalent second 
software representation based on the created reference, 
the second software representation being comprised of 
a device or service -specific API for controlling inter- 
action with a second respective set of one or more 
functionalities of the device or service in accordance 
with the second software architecture; and 

registering the second software representation such that 
software applications within the second network are 
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enabled to interact with the device or service in accor- 
dance with the second software architecture using the 
second software representation. 

2: The method of claim 1, wherein: 

one of the first and second networks is based on a HAM 
architecture; and 

the other of the first and second networks is based on a 
Home API architecture. 

3. The method of claim 1, wherein: 

one of the first and second networks is based on a Home 

API architecture; and 
the other of the first and second networks is based on a 

JIN1 architecture. 

4. The method of claim 1, wherein: 

one of the first and second networks is based on a Home 

API architecture; and 
the other of the first and second networks is based on a 

UPnP architecture. 

5. The method of claim 1, wherein: 

one of the first and second networks is based on a JINI 

architecture; and 
the other of the first and second networks is based on a 

HAVi architecture. 

6. The method of claim 1, wherein: 

one of the first and second networks is based on a JINI 

architecture; and 
the other of the first and second networks is based on a 

UPnP architecture. 

7. The method of claim 1, wherein: 

one of the first and second networks is based on a UPnP 

architecture; and 
the other network is based on a HAVi architecture. 

8. The method of claim 1, wherein: 

the first network has an inventory of devices and/or 
services registered with the first network; 

the step of detecting comprises querying the inventory, 

the step of forming comprises extracting information 
about the first software representation relevant to the 
second network; and 

the step of creating comprises providing a second soft- 
ware representation based on the information extracted. 

9. The method of claim 1, wherein the first software 
representation comprises a first software object and the 
second software representation comprises a second software 
object. 

10. An information processing system comprising: 

a first home network of a first software architecture; and 
a second home network of a second software architecture 

that is different from the first software architecture; 

wherein: 

the first network has a look-up service for detecting a 
first software representation of a first device or of a 
first service that is registered in the first network, the 
first software representation being comprised of a 
device or service-specific API that enables software 
applications within the first network to control inter- 
action with a first respective set of one or more 
functionalities of the first device or first service in 
accordance with the first software architecture; 

the system has a reference generator for creating a 
reference of the first software representation through 
interaction with the look-up service, the reference 
comprising information defining the functionalities 
performed by the device or service that are relevant 
to the second network; 
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Set top box 206 and PC 212 are interconnected through an 
IEEE 1394 bus. The IEEE 1394 connection enables PC 212 
to access IEEE 1394 compliant devices. In order to take 
advantage of this capability, a Home API Service Provider 
218 (see under ABackground Arts above or see the Home 5 
API spec.) for HAVI is installed on PC 204. HAVi-dedicated 
Service Provider 218 is capable of accessing a PC-based 
HAVi FAV-application or PC-based HAVi-IAV application 
environment. It may also implement or install an FAV or IAV 
environment itself, if none is available. Service Provider 218 ^ Q 
then populates the Home API Directory 220 with COM 
objects representing HAVi devices, e.g., representing 
devices 206-210. This enables Home API applications on 
PC 212 to control HAVi devices 206-210. 

However, this configuration does not allow HAVi-based 
applications on FAV 206 to access Home API software 15 
objects such as the ones for lights 214, lawn sprinklers 216 
and for other devices registered with Directory 220. In order 
to achieve control from HAVi network 202, a set of HAVi- 
compliant Software Elements (e.g., DCM=s, FCM=s) needs 
to be installed in a HAVi Registry 222. The invention now 20 
proposes to introduce the concepts of the Reference Factory 
and Software Element Factory in order to enable this instal- 
lation as discussed with reference to FIG. 1. This control 
capability allows the user, e.g., to turns on/off lights 214 via 
his/her HAVi set-top box 206, and to stop or reschedule 25 
sprinklers 216 to avoid noise while watching an interesting 
movie, etc. 

Block Diagrams Creating Software Configuration 

HAVi-Home API 3Q 

FIG. 3 is a first block diagram illustrating asoftware 
configuration 300 of a HAVi-Home API bridge. Configura- 
tion 300 comprises a PC 302 with a Home API control 
environment 304, and a HAVi IAV/FAV software implemen- 
tation 306. Configuration 300 also comprises HAVi network 35 
308 and a Home API network 310. HAVi -dedicated software 
elements interacting with Home API environment 304 
enable devices or services of network 310, which have 
registered with Home API environment 304 to be controlled 
from HAVi network 308. 40 

As explained above, the invention provides a method to 
enable the bridging between different home networking 
environments, here HAVi network 308 and Home API 
network 310. To this end, Home API environment 304 
comprises a software component 312, being an application 45 
or a software object and called a Reference Factory, which 
detects software representations of devices and services 
available in environment 304, e.g., an object 314. This 
detection can be done through enumeration and/or monitor- 
ing of Home API Directory 316 or accessing a Home API 50 
root or other container. Based on the capabilities of Refer- 
ence Factory 312 and/or user-preferences, a reference or a 
set of references is created associated with the software 
representation of the device or service detected. Such ref- 
erence comprises information about the software 55 
representation, e.g., object type, property descriptor, a class: 
id, an URL, an object unique identifier, an XML tag, DDI 
descriptor, etc 1 !', necessary for the creation of an equivalent 
software representation of the same device or service but 
now for use within another network, here HAVi environment 60 
304 and network 310. Factory 312 uses Home API notifi- 
cation mechanisms, such as event subscriptions or property 
routes, to detect software objects added to environment 304. 
When a software object is added to Home API environment 
304, Reference Factory 312 is notified and, if necessary, 65 
reference(s) are created and placed into a Reference Con- 
tainer 318 associated with the object added. 
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In this example, Container 318 makes the references 
available to all Home API clients. For example, Reference 
Factory 312 accesses objects of interest, e.g., as specified by 
the user, through Home API Directory 316. For example, the 
user has specified that he/she is interested in objects ALighta 
214. User preferences can be obtained by a configuration 
application/guide. The application or guide lists, for 
example, all available devices or types of devices available 
in a networking environment. It collects user input regarding 
which one(s) among them is to be accessible via another 
network. Reference Factory 312 identifies the software 
objects of interest in Directory 310 and creates a set of 
references for HAVi Software Elements, such as, but not 
limited to, ones that comprise DDI data, a Java DCM 
reference, or a Native (Binary) DCM. These references are 
placed in Reference Container 318 for ALightsa 214. After 
Reference Factory 312 is installed it is subscribed, for 
example, through the Home API event mechanism, to the 
Home API root. The installer may subscribe Factory 312 to 
a specific container or part of Home API Directory 316, such 
as ALiving Rooms, in order to be able to control Living 
Room lights only. When a new light object is added to 
network 310, Factory 312 creates a new Reference, e.g., a 
DDI descriptor and an URL for a Java package representing 
the new light. Those references then are added to Container, 
318 of the new light. 

A HAVi Software Element Factory 320 is the software 
component responsible for accessing Home API objects of 
interest. In this example, it chooses appropriate references 
from Container 318 for the object ALightsa. Factory 320 
creates HAVi Software Elements based on the references 
retrieved and using internal or external (e.g., the Internet) 
resources. See, e.g., the infrastructure as discussed in U.S. 
Ser. No. 09/160,490 (PHA 23,500) and U.S. Ser. No. 09/189, 
535 (PHA 23,527) mentioned above. PC 302 has a DCM 
Manager 322 and a Registry 324 as parts of the HAVI 
IAV/FAV implementation on PC 302. Factory 320 interacts 
with HAVi DCM Manager 322 and HAVi Registry 324 
according to HAVi architecture rules and/or Element Factory 
preferences. For example, Factory 320 creates DDI data in 
order to make the functionality of Home API object 
ALightsa accessible via a display and HAVi applications 
hosted by HAVi network 308. Alternatively or subsidiarily, 
Factory 320 creates or retrieves from the Internet (via a 
URL) a Java DCM and registers it with Registry 324 so as 
to enable HAVi applications or other DCMs to interact with 
the software representation of ALightsa 214. 

As to the installation of Reference Factory 302, this can 
be enabled by, e.g., a device manufacturer during device 
installation on the network. For example: Philips lights can 
be packaged with PC software comprising Reference Fac- 
tory software object 302 to enable HAVi access. The instal- 
lation can be taken care of by a Service Provider, by the user 
his/herself or by a third party as part of a PC software 
functionality upgrade. 

As to installation of Software Element Factory 320, this 
may be installed by a HAM Service Provider or by a third 
party, the user him/herself or a Service Provider to upgrade 
an existing Element Factory. 

FIG. 4 is a second block diagram illustrating a software 
configuration 400 of a HAVi-Home API bridge. Configura- 
tion 400 comprises a PC 302 with a Home API control 
environment 304 and Home API network 310. Configuration 
400 also comprises HAVi network 308 including a HAVi 
FAV 402. Now, PC 302 has a software module 404 for 
representing Home API control environment 304 on HAVi 
network 308. Module 404 is a HAVi BAV that comprises 
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the system has a software element generator for creat- 
ing an at least partly functionally equivalent second 
software representation based on the reference, the 
second software representation being comprised of a 
device or service-specific API for controlling inter- 
action with a second respective set of one or more 
functionalities of the first device or first service in 
accordance with the second software architecture; 
and 

a second look-up service associated with the second 
network and configured to register the second soft- 
ware representation such that software applications 
within the second network are enabled to interact 
with the device or service in accordance with the 
second software architecture using the second soft- 
ware representation. 
11. A software component for use on a home environment 
system, comprising: 

a first network of a first software architecture, and a 
second home network of a second software architecture 
different from the first software architecture; 
the first network has a look-up service for detecting a first 
software representation of a first device or of a first 
service that is registered in the first network, the first 
software representation being comprised of a device or 
service-specific API that enables software applications 
within the first network to control interaction with a 
first respective set of one or more functionalities of the 
first device or first service in accordance with the first 
software architecture; 
a reference generator for creating a reference to the first 
software representation through interaction with the 
look-up service, the reference comprising information 
defining the functionalities performed by the device or 
service that are relevant to the second network; 
a container for storing the reference; 
a software element generator configured to retrieve the 
reference from the container and create an at least 
partly functionally equivalent second software repre- 
sentation based on the reference, the second software 
representation being comprised of a device or service - 
specific API for controlling interaction with a second 
respective set of one or more functionalities of the first 
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device or first service in accordance with the second 
software architecture; and 
a second look-up service associated with the second 
network and configured to register the second software 
representation such that software applications within 
the second network are enabled to interact with the 
device or service in accordance with the second soft- 
ware architecture using the second software represen- 
tation. 

12. A software component for use on a home environment 
system, comprising: 

a first network of a first software architecture, and a 
second network of a second software architecture dif- 
ferent from the first software architecture; 

the first network has a look-up service for detecting a first 
software representation of a first device or of a first 
service that is registered in the first network, the first 
software representation being comprised of a device or 
service-specific API that enables software applications 
within the first network to control interaction with a 
first respective set of one or more functionalities of the 
first device or first service; 

the first network has a reference to the first software 
representation, the reference comprising information 
defining the functionalities performed by the device or 
service that are relevant to the second network; 

the component has a software element generator for 
creating an at least partly functionally equivalent sec- 
ond software representation based on the reference, the 
second software representation being comprised of a 
device or service-specific API for controlling interac- 
tion with a second respective set of one or more 
functionalities of the first device or first service in 
accordance with the second software architecture; and 

a second look-up service associated with the second 
network and configured to register the second software 
representation such that software applications within 
the second network are enabled to interact with the 
device or service in accordance with the second soft- 
ware architecture using the second software represen- 
tation. 
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